@samdoran @jbpratt (#1457) what are your use cases?

IMO returning this type of metadata should not be the clone task's responsibility (nor should it have to return commit-timestamp #1040 (review), but we got bullied into accepting that one because "it is needed to unblock RHEL AI")

For custom git metadata needs, it would be best if you just ran whatever script you want in your own pipeline. But writing Tekton tasks can be annoying, so I understand why you would want this as a task result...

Though to be fair, the technical limitation of returning all the git metadata one could possibly want should be fixable by enabling https://tekton.dev/docs/pipelines/tasks/#larger-results-using-sidecar-logs

And I suppose it would be nice for the clone task to provide all the results out of the box. It might not "do one thing well," but it would be convenient 😄

/ok-to-test

Hey @chmeliik , here is the thread where I discussed my use case with others! https://redhat-internal.slack.com/archives/C031USXS2FJ/p1726817746562859?thread_ts=1726244072.482159&cid=C031USXS2FJ

what are your use cases?

My use case is similar to what @jbpratt described with a few extra caveats. The short commit hash is available in the release pipeline, so we use that to tag release image. It would be nice to have parity between test and release image tags.

I want to reference the Konflux build images (redhat-user-workloads) to run integration tests. For reasons, we use the image tag as a name for a clowder job invocation. That name is limited to 63 characters (also for reasons?), so bonfire deploy fails because the name field is too long.

I would prefer if this was avalible in PAC as a dynamic variable. But I don't have the ability to change that (since it requires a code change and release) whereas I can modify Tekton tasks.

This is kinda gross but works (parameter to add-tags task): pr-{{ body.pull_request.number }}-$(tasks.clone-repository.results.short-commit)

For custom git metadata needs, it would be best if you just ran whatever script you want in your own pipeline. But writing Tekton tasks can be annoying, so I understand why you would want this as a task result

For another one of our applications, I wrote a custom task to run a script to get the desired version and that was quite painful.

I don't mind making my own task and keeping it to myself, but it seems like having the short SHA would be beneficial to others. Especially since many of us are coming from app-interface where we have a long history of using the short commit SHA in many places.

I'll address the failing tests.

Just need to re-generate git-clone-oci-ta again

I fixed the failures related to git-clone-oci-ta.

Ah, one more thing. @samdoran if you don't mind, could you squash the commits?

Sure thing!

Thank you for merging and all the great reviews!